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ARI  Research  Reports  and  Technical  Reports  are  intended  for  sponsors  of 
R&D  tasks  and  for  other  research  and  military  agencies.  Any  findings  ready 
for  implementation  at  die  time  of  publication  are  presented  in  the  last  part 
of  the  Brief.  Upon  completion  of  a  major  phase  of  the  task,  formal  recom¬ 
mendations  for  official  action  normally  are  conveyed  to  appropriate  military 
agencies  by  briefing  or  Disposition  Form. 


FOREWORD 


The  Human  Factors  Technical  Area  of  the  Army  Research  Institute 
(ARI)  is  concerned  with  the  human  resource  demands  of  increasingly  complex 
battlefield  systems  designed  to  acquire,  transmit,  process,  disseminate, 
and  utilize  information.  Research  focuses  on  human  performance  problems 
related  to  interactions  within  command-and-control  centers  as  well  as 
issues  of  system  development,  performance,  effectiveness,  and  efficiency. 
It  is  concerned  with  such  areas  as  software  development,  topographic 
products  and  procedures,  tactical  symbology,  user-oriented  systems,  infor¬ 
mation  management,  staff  operations  and  procedures,  decision  support,  and 
sensor  systems  integration  and  utilization. 


Of  special  interest  are  the  human  factors  problems  related  to  the 
integration  of  human  functions  into  information-processing  systems  and 
to  the  harmonizing  of  system  components,  personnel,  and  operations  in  a 
battlefield  environment.  To  incorporate  human  functions  and  performance 
into  simulated  system  operations,  a  research  program  at  ARI  developed  a 
computer  simulation  of  a  generalized  human  information  processing  model 
(MANMOD).  MANMOD  permits  study  of  system  operations  and  performance  under 
prescribed  as  well  as  alternative  personnel  and  equipment  configurations. 


This  report  describes  the  interface  of  MANMOD  with  two  computer  models, 
CASE  and  SAMTOS,  of  the  Army's  tactical  operations  system  (TOS).  This 
effort  supported  the  Army's  cost-effectiveness  analysis  of  TOS  (CEATOS)  and 
the  investigation  of  alternative  TOS  configurations.  Earlier  reports  in 
the  series  described  sequential  versions  of  MANMOD:  batch  processing  in 
Volume  I  (ARI  technical  report  TR-77-A23),  on-line  processing  in  Volume  II 
* (TR-77-A24) ,  and  interactive  in  Volume  HI  (TR-77-A25).  ARI  Technical 
-Report  414  (Volume  V)  provides  a  user’s  guide  to  the\integrated  MANMOD/CASE/ 
SAMTOS  simulation  described  here  in  Volume  IV.  Also,, ARI  publications 
,<lTR-77-A22  and  Technical  Report  407  describe  a  second -generation  model, 
NETMAN,  developed  on  the  basis/of  MANMOD  research. 

A**/  >'*.  '  A  '  '  ' 

Research  on  systems  integration  and  operations  is  conducted  as  an 
in-house  effort  augmented  through  contracts  with  organizations  selected  for 
their  unique  capabilities  and  facilities  for  research  and  development  on 
human  performance  and  computer  simulation.  This  report  represents  research 
by  personnel  from  ARI  and  Applied  Psychological  Services,  Inc.,  under 
contract  DAHC19-75-C-0001 .  The  effort  is  responsive  to  general  requirements 
of  Army  Project  2Q762722A765  and  to  special  requirements  of  the  U.S.  Army 
Combined  Arms  Combat  Development  Activity.  Special  requirements  are 
contained  in  Human  Resources  Need  76-161,  "MAN  MODEL  interface  with  other 
CEATOS  support  models." 
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A  DIGITAL  SIMULATION  MODEL  OF  MESSAGE  HANDLING  IN  THE  TACTICAL  OPERATIONS 
SYSTEM:  IV.  Model  Integration  with  CASE  and  SAMTOS 


BRIEF 


Requirement : 

To  improve  the  SAMTOS  computer  model  of  the  Army's  tactical  operations 
system  (TOS)  for  cost-effectiveness  analysis,  by  enhancing  its  capability 
to  simulate  the  information-processing  performance  of  personnel.  CASE 
a  simulates  the  TOS  communications  network  and  estimates  the  effects  on  TOS 

performance  of  number  of  components  and  network  variations.  SAMTOS 
simulates  the  TOS  computer  hardware  and  software.  MANMOD  simulates  activ- 
«  ities  within  a  communications  station  and  assesses  the  effects  of  operator 

characteristics  on  message-handling  performance,  to  provide  estimates  of 
human  performance  parameters. 


Procedure: 

CASE  was  interfaced  with  MANMOD  to  permit  the  transfer  of  network 
equipment  parameter  estimates  to  MANMOD.  MANMOD' s  human  performance 
parameters  were  input  to  SAMTOS.  In  addition,  MANMOD  was  enhanced  to 
improve  the  simulation  of  errors  in  message  processing.  All  MANMOD  modifi¬ 
cations  were  tested  for  sensitivity  and  reasonableness. 


Product : 

Integration  of  the  three  simulations  required  only  minor  modifications 
to  CASE  and  none  to  SAMTOS.  Sensitivity  tests  of  the  previously  validated 
MANMOD  supported  the  effectiveness  of  the  modifications.  All  changes  in 
MANMOD  output  parameters  were  in  the  expected  directions,  although  in  the 
absence  of  appropriate  criterion  data  the  magnitude  of  those  changes  was 
not  tested. 


Utilization: 

The  integration  of  the  three  computer  simulations  provides  a  useful 
tool  for  analyzing  and  designing  alternative  system  configurations.  Within 
the  limits  imposed  by  the  lack  of  appropriate  data  for  validating  the 
model,  system  effectiveness  and  other  figures  of  merit  can  be  obtained  for 
alternative  system  configurations.  These  alternatives  can  reflect  differences 
in  personnel  characteristics,  manning  levels,  message  traffic  loads, 
equipment  capabilities,  performance,  or  message  types.  Results  can  provide 
insights  on  equipment  design,  training  and  personnel  requirements,  and  the 
tradeoffs  necessary  for  optimum  cost  effectiveness. 
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INTRODUCTION 


This  report  constitutes  the  fourth  in  a  series  which  documents  the 
development. and  evaluation  of  the  MANMOD,  a  stochastic,  digital  simula¬ 
tion  model  for  simulating  the  acts  and  behaviors  of  the  personnel  involved 
in  the  operation  of  the  U.  S.  Army's  Tactical  Operations  System  (TOS). 

The  TOS,  although  still  in  the  developmental  and  test  stages,  is 
intended  as  a  part  of  an  overall  integrated  Battlefield  Control  System 
(IBCS),  in  which  it  will  serve  the  information  collection  and  dissemina¬ 
tion  functions.  The  information  system  is  also  intended  to  provide  trans¬ 
mission  of  orders,  information  requests,  and  practically  any  information 
concerning  the  battlefield  situation.  The  system  design,  as  currently  con¬ 
ceived,  is  documented  in  some  detail  in  Tactical  Operations  System;  Oper¬ 
able  Segment,  System  Engineering  Study  Report  (1972).  The  TOS  has  been 
tested  in  different  configurations  in  the  field  both  in  Europe  and  the  U.  S.  A. 
A  simplified  TOS  has  been  experimentally  studied  in  the  laboratory  (e.  g. , 
Baker,  1970;  Baker,  Mace,  &  McKendry,  1969). 

The  MANMOD  was  designed  to  function  in  parallel  with  such  experi¬ 
mental  studies  and  complement  their  findings. 

Otfter  computer  simulation  models  (CASE  and  SAMTOS)  of  the  TOS 
have  been  developed  elsewhere.  These  models  approach  the  simulation  in 
different  ways  and  possess  different  objectives  from  the  MANMOD.  The 
MANMOD  generally  allows  the  capability  to  study  the  effects  of  varying 
operator  and  manning  considerations  on  message  processing  effectiveness. 
The  CASE  and  the  SAMTOS  models  are  more  concerned  with  equipment 
functions  with  (more  or  less)  constant  human  operators  in  the  loop. 


Initial  MANMOD  Development 


In  the  initial  MANMOD  development,  the  model  was  organized  so 
as  to  assess  the  effects  of  varying  operator  characteristics  on  message 
processing  speed  and  accuracy.  Operator  characteristics  considered  in 
this  initial  simulation  model  were: 

•  speed 

•  precision 

•  level  of  aspiration 

•  stress  threshold 

•  fatigue 

The  initial  development  also  allowed  study  and  analysis  of  the  effects  of 
message  characteristics  such  as: 


•  arrival  frequency 

•  arrival  distribution 

•  length 

•  type 

•  priority 


The  output  or  description  of  the  resulting  simulation  was  partitioned 
in  five  ways  in  order  to  provide  a  complete  picture  of  the  simulation  per¬ 
formance.  These  five  categories  are: 


•  manpower  utilization 

•  message  processing  times 

•  effectiveness 

•  workload  summary 

•  error  summary 


The  model  simulates  the  activities  within  a  single  communication 
station  in  the  TOS  field  army  situation.  The  station  is  manned  by  a  single 
G-3  (operations)  officer,  and  may  include  one  or  more  action  officers. 

These  men  receive  messages  of  various  types  which  are  delivered  to  the 
station  at  times  unknown  in  advance  of  the  simulation.  Their  function  is  to 
screen  incoming  messages,  decide  on  the  order  in  which  they  are  to  be  proc¬ 
essed,  and  to  select  the  appropriate  message  form  to  which  they  transform 
the  content  of  each  message  to  be  entered  into  the  TOS  data  bank.  One  class 
of  simulated  messages  is  "generated"  by  tjhe  MANMOD  at  random  times.  The 


other  class  involves  situation  reports  which  are  assumed  to  arrive  only 
during  the  last  quarter  of  a  given  hour.  To  process  both  classes  of  mes¬ 
sage  further,  the  performance  of  one  or  more  UIOD  operators  is  simu¬ 
lated.  Working  from  the  queue  of  message  forms  prepared  by  the  offi¬ 
cers,  the  UIOD  enter  each  message  into  the  TOS  system  using  a  keyboard 
and  CRT  edit/ verify  device.  The  purpose  of  the  model  is  to  simulate  these 
personnel  on  an  hour-by-hour  basis  over  a  single  work  shift. 

Although  the  above  general  task  assignment  to  operators  and  the 
sequencing  thereof  is  the  current  approach,  the  MANMOD  treats  these  as 
soft.  Since  they  are  controlled  by  input  data,  they  may  be  readily  changed. 

The  computer  program  written  in  the  FORTRAN  IV  language  was 
designed  for  the  CDC  3300  computer.  The  model  handles  up  to  6  men  of 
2  types  (any  combination  of  Action  Officers  and  UIOD's),  4  types  of 
operator  errors,  7  types  of  messages,  and  5  message  priority  classifi¬ 
cations. 


Figure  1,  taken  from  Siegel,  Wolf,  and  Leahy  (1973a),  shows  the  sub¬ 
routines  and  their  interrelation  with  the  main  processing  flow.  Following 
data  read-in,  there  is  an  optional  recording  of  the  input  data.  Conditions 
are  then  reset  (circle  b  of  Figure  1)  for  the  start  of  simulation  for  a  new 
TOS  shift.  The  backlog  subroutine  (BAKLOG)  generates  data  representing 
messages  in  the  Action  Officer's  "in-box"  at  the  start  of  each  iteration.  At 
circle  c  of  Figure  1,  following  reset  of  counters  and  registers  for  record 
keeping  of  hourly  results,  the  message  generation  subroutine  develops  data 
representing  messages  which  will  arrive  during  the  coming  hour.  These 
are  merged  with  the  backlog  in  order  by  time  of  arrival,  and  the  contents 
of  this  hourly  message  queue  is  optionally  recorded.  At  circle  d  of  Figure  1, 
the  processing  of  each  message  in  turn  by  a  single  operator  (either  G-3,  Ac¬ 
tion  Officer,  or  UIOD  operator)  begins.  The  Man  Determination  Subroutine 
selects  the  appropriate  man  to  simulate  next,  and  determines  the  next  avail¬ 
able  appropriate  message  for  this  selected  man  to  process.  The  operator 
stress  and  aspiration  conditions  applicable  to  that  operator  message  situa¬ 
tion  are  calculated  next.  At  this  point  (circle  j),  all  data  are  available  for 
the  detailed  task  element-by-task  element  simulation  for  the  message  and 
operator  selected.  This  is  accomplished  by  the  Operator  Processing  Sub¬ 
routine,  which  manipulates  mission  task  analysis  data.  During  this  sub¬ 
routine,  the  detailed  results  of  the  simulation  of  the  performance  of  each 
task  element,  as  well  as  the  summary  results  for  this  one  message,  may 
be  optionally  recorded  for  printing. 
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Following  this,  queues  are  adjusted  and  the  cycle  repeats  back  to 
circle  d  for  processing  of  all  messages  which  can  be  handled  before  the 
next  one  hour  segment  is  completed.  When  the  end  of  an  hour  condition 
is  reached  for  all  men,  the  results  of  the  hour's  simulated  activity  are 
optionally  printed.  The  process  of  simulating  in  one  hour  segments  is 
repeated  (back  to  circle  c)  until  the  simulation  of  one  iteration  of  an  en¬ 
tire  shift  is  completed.  When  a  shift  iteration  is  finished,  the  iteration 
summary  subroutine  generates  summary  data  over  the  shift.  The  pro¬ 
cess  is  repeated  (back  to  circle  b)  for  each  iteration  and  after  all  iterations 
are  complete,  the  run  summary  subroutine  summarizes  and  records  all  the 
pertinent  performance  figures  to  complete  a  simulation  run.  Multiple  runs 
are  processed  sequentially  through  the  entire  process  by  returning  to  the 
input  subroutines  at  circle  a  of  Figure  1  and  processing  as  many  sets  of 
data  as  are  provided  as  input. 

In  the  first  stage  of  the  development  of  MANMOD,  the  model's  out¬ 
put  was  verified  through  a  comparison  with  independently  collected  criterion 
data.  Substantial  correspondence  was  indicated  between  the  criterion  data 
and  the  predictions  of  MANMOD. 


Further  Development  of  MANMOD 

Having  achieved  a  simulation  which  appeared  to  possess  merit,  the 
initial  version  of  MANMOD  was  revised  to  allow  online  modification  of  simu¬ 
lation  parameters  through  an  interactive  terminal.  This  modification  allow¬ 
ed  for  increased  flexibility  in  model  employment.  The  original  model  called 
for  card/tape  data  input  and  allowed  for  output  in  the  usual  printed  computer 
tabulation  form.  The  revision  allowed  an  active  "conversation"  between  the 
model  and  its  user  because  the  revision  provided  online  data  input  and  im¬ 
mediate  presentation  of  results  on  the  terminal's  cathode  ray  tube.  With 
the  interactive  feature,  the  model's  user  could  easily  and  quickly  explore 
alternatives  and  variations  suggested  by  a  set  of  simulation  runs. 

Additional  enhancements  incorporated  during  this  first  model  revi¬ 
sion  included: 


1.  revision  of  the  responsiveness  formula  in  the  sys¬ 
tem  effectiveness  calculation  and  a  correction  of 
the  formula  for  calculating  the  system  effective¬ 
ness  index 
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2.  addition  of  the  capability  to  generate  more  than  one 
TOS  message  from  a  single  input  message 

3.  correction  of  the  calculation  for  the  number  of  un¬ 
detected  errors 

4.  incorporation  of  the  effects  of  message  priority  on 
operator  stress 

5.  extension  of  the  existing  limit  from  one  shift  of  up 
to  12  hours  to  as  long  as  24  hours  (including  up  to 
four  shifts) 

6.  improvement  in  the  content  and  format  of  the  printed 
output 


In  the  third  developmental  phase,  the  interactive  model  was  extended 
to  process  simultaneously  a  combination  of  real  data  as  provided  by  physical 
simulation  and  computer  simulation  data.  In  this  mode,  an  experimental  sub¬ 
ject  performs  part  of  the  task(s)  simulated.  The  subject  data  are  recorded 
on  disk  and  combined  with  the  computer  simulation  generated  data  to  provide 
an  integrated  result.  This  mode  of  operation  was  called  the  subject  inter¬ 
active  mode.  In  this  mode,  an  experimenter  seated  at  a  terminal  can: 

1.  select,  enter,  and  verify  run  and  operator  parameters 

2.  specify  number  and  cathode  ray  tube  assignment  of 
subjects 

3.  designate  which  tasks  in  a  task  analysis  list  a  subject 
is  to  perform 

4.  monitor  the  messages  generated  and  specify  those 
which  are  to  be  performed  by  subjects 

5.  monitor  results  of  each  hour's  processing  by  both 
computer  simulation  and  subject 

6.  observe  subject  actions  and  indicate  times  of  start 
and  end  of  tasks 

7.  monitor  subject  performance  times 

Figure  2  presents  the  flow  of  data  in  this  computer-experimenter-sub¬ 
ject  interactive  mode. 
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FIGURE  2.  SYSTEM  FLOW  FOR  THE  COMPUTER-EXPERIMENTER, 
SUBJECT  INTERACTIVE  MODE 


A  second  part  of  the  subject  interactive  mode  allowed  the  computer 
to  call  the  subject  interactive  data  from  disk,  average  it  to  provide  new 
human  performance  data,  and  then  use  these  data  in  a  new  simulation  which 
may  be  stochastically  repeated  across  many  varied  iterations.  The  re¬ 
sults  from  suc,h  a  stochastic  combination  of  events  across  many  iterations 
have  been  found  to  provide  a  more  consistent,  representative,  and  replicable 
picture  of  simulated  events. 

Purpose  of  Present  Work 

The  general  purpose  of  the  effort  here  reported  was  to  produce  a  more 
useful  and  more  powerful  version  of  the  MANMOD  for  simulating  the  TOS  net¬ 
work.  The  specific  purposes  included: 

•  allowing  for  automatic  transfer  of  data  between 
MANMOD  and  complementary  simulation  models 

•  modifying  the  MANMOD  so  that  it  can  be  run  on 
the  U  1103  computer  system 

•  increasing  the  verisimilitude  of  the  model  through 
incorporation  of  error  message  evaluation  and  inter¬ 
ruption  features 


The  details  of  this  work  are  presented  in  Chapter  II  of  this  report. 
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CHAPTER  II 


PROGRAM  DETAILS 


As  stated  at  the  conclusion  of  Chapter  I,  the  present  program  pos¬ 
sessed  a  diversified,  but  interrelated,  set  of  purposes.  Achievement  of 
each  of  these  purposes  provides  the  Army  with  a  fully  articulated  and  in¬ 
tegrated  model  which  allows  simulation  of  the  TOS  system  in  a  highly  flex¬ 
ible  manner.  The  reader  who  is  interested  in  a  complete  guide  to  the 
operational  and  functional  details  for  the  final  model  should  consult  the 
User's  Guide  to  the  Integrated  MANMOD/CASE/SAMTOS  Computer  Simu¬ 
lation,  which  forms  a  separate  appendix  to  the  present  technical  report. 


Data  Transfer  between  Various  Models 

Over  the  past  few  years,  three  separate  models  have  been  developed 
to  simulate  various  aspects  of  the  TOS.  One  such  model,  MANMOD,  was 
briefly  described  above.  Another  model,  the  Communications  Analysis  Sim¬ 
ulation  and  Evaluation  (CASE)  model  simulates  a  large  network  communica¬ 
tions  system,  including  the  TOS  system,  as  well  as  more  commonly  used 
phone  and  written  message  systems.  The  model  was  designed  to  determine 
the  effects  of  number  of  components  and  network  variations  on  overall  sys¬ 
tem  function. 

A  third  computer  model,  SAMTOS,  was  developed  by  the  U.  S.  Army 
Electronics  Command,  and  has  already  gone  through  several  revisions. 
SAMTOS  principally  locates  queuing  and  hardware  bottlenecks  within  a  sys¬ 
tem  as  a  function  of  such  variables  as  transmission  rate  and  number  of  chan¬ 
nels..  Although  some  human  performance  effects,  such  as  operator  keying 
rate,  are  simulated,  the  human  operator  is  treated  within  this  model  as  a 
static  component. 

The  logic  for  the  integration  of  MANMOD,  CASE,  and  SAMTOS  is 
presented  in  Figure  3.  Specifically,  the  CASE  model  was  revised  by  the 
Systems  Analysis  Section,  Plans  and  Analysis  Division,  U.  S.  Army  Elec¬ 
tronics  Command,  so  that  it  can  be  implemented  on  the  U  1108  computer  sys¬ 
tem.  In  completing  this  revision,  the  CASE  model  aspects  of  interest  for  the 
required  integration  were  programmed  in  the  GERTS  programming  language. 
This  language  is  particularly  useful  when  one  or  more  networks  are  involved 
in  a  simulation.  Full  details  of  the  revised  CASE  are  presented  in  Appendix  A 
to  this  report.  In  the  present  application,  the  system  delay  time  output  of  the 
revised  CASE  model  is  stored  in  a  file  accessible  by  MANMOD.  Accordingly, 


FIGURE  3.  COUPLING  BETWEEN  CASE,  MANMODE L,  AND  SAMTOS  SIMULATIONS 


IP 


MANMOD  accepts  the  system  delay  time  generation  of  CASE  and  employs 
these  delay  time  data  in  its  normal  simulation  of  the  acts  and  behaviors  of 
the  operators  as  they  process  incoming  messages.  Finally,  the  output  of 
the  combined  CASE  and  MANMOD  can  be  printed  and  punched  on  cards  in  such 
a  manner  that  the  punched  cards  can  be  used  as  direct  entry  into  SAMTOS. 

In  this  manner,  a  simulation  is  accomplished  which  consolidates  the  three 
separate  models  and  which  incorporates  the  major  features  and  advantages 
of  each- -the  sophisticated  delay  time  generation  of  CASE,  the  human  action 
simulation  of  MANMOD,  and  the  queuing  effects  and  variable  load  simulation 
of  SAMTOS. 

Although  the  integrated  model  can  be  processed  in  its  entirety  through 
card  input,  it  is  also  designed  to  be  controlled  by  user  interaction  through  a 
terminal.  As  shown  at  circle  1  of  Figure  3,  the  revised  CASE  program  is 
called  first.  This  activation  causes  several  files  to  be  read,  and  the  program 
begins.  After  the  entry  of  customary  parameters,  the  user  is  queried  as  to 
whether  or  not  a  file  should  be  written  for  MANMOD.  If  the  user  so  indicates, 
the  CASE  simulation  proceeds.  After  the  CASE  simulation  is  completed,  the 
resulting  delay  time  data  are  displayed  to  the  user's  terminal.  The  user  may, 
at  his  option  have  the  regular  output  file  printed  or  wait  until  some  later  time. 
The  revised  CASE  program  writes  the  delay  time  data  to  a  special  data  file 
(-TNTERACTCASE)  as  well  as  to  the  user's  terminal. 

The  user  must  allow  the  CASE  simulation  to  proceed  to  normal  termina¬ 
tion  and  then  call  the  MANMOD.  Once  activated,  the  MANMOD  executes  its 
normal  card  input  routines  and  then  enters  an  interactive  mode.  This  mode 
allows  the  user  to  examine  and  change  parameters.  The  user,  at  this  time, 
can  either  call  in  the  CASE  generated  data  from  file  *  JN  TER  A  C  T  C  A  SE  or  he 
can  provide  his  own  data  for  these  variables.  When  the  interaction  data  are 
called,  the  nodes  of  interest  must  be  specified.  Then  the  mean  durations 
of  the  delays  . are  computed  and  displayed  to  the  experimenter. 

The  option  to  write  data  to  file  *INTERACTSAM  is  also  provided  to 
the  user.  These  data  consist  of  human  performance  times  due  to  stress, 
fatigue,  workload,  and  operator  characteristics.  This  file  can  be  printed 
or  punched  on  cards  for  the  use  of  the  SAMTOS  model  in  its  simulations. 

The  integrated  model  is  now  operational  on  the  U  1108  system  and  is 
fully  documented  in  the  User's  Guide  to  the  Integrated  MANMOD/ CASE/ 
SAMTOS  Compute  r  Simulation. 
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Error  Message  Processing  and  Interruption 
_ Feature  Augmentation  of  MANMOD _ 


While  MANMOD  has  been  considered  to  incorporate  sufficient  detail 
to  allow  simulation  of  most  aspects  of  human  activity  during  message  pro¬ 
cessing  in  the  TOS  system,  two  features,  not  previously  or  only  minimally 
considered,  were  believed  to  be  of  sufficient  import  as  to  warrant  considera¬ 
tion  for  inclusion  or  expansion  in  the  MANMOD  simulation.  These  features 
were:  error  message  processing  and  interruption.  Each  of  these,  together 
with  the  appropriate  description  of  the  method  of  implementation  in  the 
MANMOD,  is  described  in  the  succeeding  paragraphs. 


Error  Message  Processing 

Whenever  an  operator  enters  a  message  into  the  TOS  computer  sys¬ 
tem,  the  message  is  either  acknowledged  or  rejected.  In  the  case  of  a  re¬ 
jected  message,  an  "error  message"  is  displayed  to  the  operator.  Examples 
of  possible  error  messages  are  shown  in  Figure  4.  These  messages  are 
quite  brief.  Although  they  identify  the  problem  in  some  general  manner,  they 
do  not  indicate  the  corrective  action  required.  When  he  receives  an  error 
message,  the  operator  must  read  the  error  message,  determine  the  required 
correction,  make  the  correction,  and  enter  a  modified  message.  When  the 
operator  transmits  the  modified  message,  it  may  or  may  not  be  correct.  On 
occasion,  the  appropriate  correction  may  not  be  known  to  the  operator.  In 
this  case,  the  operator  will  consult  other  available  courses  such  as  other  per¬ 
sonnel  or  available  manuals  and  documentation. 

Previously  an  error  message  processing  feature  was  included  in  the 
MANMOD  simulation.  However,  this  simulation  aspect  was  somewhat  barren. 
Accordingly,  a  new  error  message  processing  logic  was  developed  and  incor¬ 
porated  into  the  MANMOD. 

In  its  current  form,  the  error  message  processing  subroutine  is  based 
on  two  separate  concepts- -the  vocalic  center  group  concept  and  decision  mak¬ 
ing  in  a  choice  decision  situation. 


The  Vocalic  Center  Group  Concept 

In  order  to  process  an  error  message  the  operator  must  first  recog¬ 
nize  the  meaning  of  the  message.  Having  extracted  the  meaning,  he  must  then 
derive  an  appropriate  correction  action  pathway. 


UNIT  NOT  FOUND 

ORIG-CODE  DUPLICATES  EXISTING  ENTRY 
TASK  FORCE  NAME  CURRENTLY  IN  USE 
DUPLICATE  NAME-OR-NO  FOR  TYPE  DATA 
NAMED  ARE  NOT  FOUND 

VICINITY  OF  NEEDED  FOR  NEW  SITREP 
MESSAGE  OUTDATED 
ONLY  G  2  MAY  USE  E  W  FA 


Figure  4.  Examples  of  error  messages. 
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The  perception  of  the  meaning  aspect  of  the  simulation  is  based  on 
the  Vocalic  Center  Group  (VCG)  concept  reported  by  Spoehr  and  Smith 
(1973)  and  Smith  and  Spoehr  (1974).  In  this  concept: 

...when  a  word  is  presented,  features  of  each  letter 
position  are  first  extracted  and  then  matched  to  in¬ 
dividual  letter  categories.  The  categorized  informa¬ 
tion  is  then  placed  in  a  sensory  store.  The  function 
of  this  store  is  to  maintain  the  visual  information 
long  enough  for  some  orthographically  dependent  pars¬ 
ing  process  to  segment  the  letter  string  into  higher- 
order  units,  called  VCGs,  so  that  a  subsequent  trans¬ 
lation  process  can  assign  an  acoustical  code  to  each 
unit.  It  is  not  until  the  translation  process  is  com¬ 
pleted  that  perceptual  processing  is  assumed  to  be 
over  (Smith  6  Spoehr,  1974,  p.260). 

A  vocalic  center  group  is  defined  by  Smith  and  Spoehr  as  "a  letter  se¬ 
quence  that  contains  one  vocalic  element,  a  single  vowel  or  dipthong,  and 
from  zero  to  three  consonants  or  semi-consonantal  elements  preceding  or 
following  the  vocalic  element  (p,  260).  " 

To  derive  the  number  of  vocalic  center  groups  in  a  word.  Smith  and 
Spoehr  present  a  number  of  parsing  rules.  Spoehr  and  Smith  (1972)  demon¬ 
strated  that  any  letter  string  that  forms  a  single  vocalic  center  group  is  more 
perceptible  than  words  containing  two  vocalic  center  groups. 

We  assume  that  an  increase  in  the  number  of  vocalic  center  groups 
within  an  error  message  is  associated  with  an  increase  in  the  complexity 
and  in  the  ambiguity  of  a  message.  The  effect  of  increasing  ambiguity  within 
an  error  message  is  assumed  to  decrease  the  probability  that  an  error  mes¬ 
sage  will  be  followed  by  an  immediate  revision  of  the  UIOD  entered  message. 


Decision  Making 

To  simulate  the  decision  making  aspect  of  the  error  message  correc¬ 
tion,  a  random  walk  model  is  employed  (Lansing,  1968).  Figure  5  shows 
an  example  of  this  model. 


Solution 


No 

Solution 


Figure  5.  Random  walk  process. 
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Five  points,  labeled  A  through  E,  are  shown  with  interconnecting  lines.  A 
and  E  are  called  absorbing  states  which  in  our  usage  correspond  to  arriving 
at  the  right  (A)  solution  or  no  (E)  solution.  Depending  on  the  level  of  am¬ 
biguity  in  the  error  message,  the  decision  process  may  be  started  at  either  B 
(very  close  to  a  solution),  C  (midway  between  solution  and  no  solution),  or  D 
(very  close  to  no  solution).  Probabilities  are  entered  for  the  chances  that  a 
decision  will  move  toward  or  away  from  a  solution  and  the  actual number  of 
steps  (stochastically  determined  during  a  simulation)  are  counted  and  used 
to  compute  the  decision  time. 


Error  Message  Logic  Flow 

Figure  6  presents  an  overall  flow  chart  of  the  error  message  process¬ 
ing.  In  the  normal  simulation  mode,  the  number  of  incorrect  transmissions 
is  computed.  An  error  message  is  randomly  selected  and  processed.  The 
level  of  ambiguity  is  computed  and  used  in  conjunction  with  the  random  walk 
model  to  determine  whether  or  not  a  solution  was  reached  and  how  much  time 
was  required.  If  a  solution  is  not  initially  found  the  simulated  operator  starts 
exploring  other  avenues  such  as  querying  another  operator  or  consulting  refer¬ 
ence  materials.  Data  storage  for  up  to  ten  options  is  provided  and  the  time 
and  probability  descriptors  of  each  option  are  provided  as  input  data.  Per¬ 
forming  any  of  the  information  seeking  options  is  assumed  to  reduce  the  level 
of  ambiguity  and  initiate  another  random  walk  solution  process. 


Details  of  Error  Message  Processing 

Figure  7  further  details  the  error  message  processing.  First,  the 
presence  of  an  operator  error  is  noted  and  an  error  message  is  selected 
from  a  stored  library  of  error  messages.  All  error  messages  are  assumed 
to  be  equally  probable.  Each  error  message  possesses  a  predetermined  num¬ 
ber  of  vocalic  center  groups  (NVG).  These  have  been  obtained  by  an  actual 
count  of  the  number  of  vocalic  center  groups  in  available  error  messages. 

The  relationship  between  the  number  of  vocalic  center  groups  and  starting 
point  within  the  random  walk  is  an  input  parameter.  Positions  1  and  5  are 
the  absorbing  states  within  the  random  walk  (i.  e. ,  termination  points).  Ab¬ 
sorption  at  position  1  represents  reaching  a  solution  which  is  immediately 
implemented,  while  absorption  at  position  5  represents  reaching  no  immedi¬ 
ate  solution,  thereby  necessitating  reference  to  other  sources  of  information. 
When  a  solution  is  found,  this  solution  is  used  to  modify  the  message  and  the 
message  is  transmitted.  The  time  to  enter  this  message  modification  is  se¬ 
lected  from  a  uniform  distribution  with  a  mean  of  AVCOR  and  a  standard  devi¬ 
ation  of  SDCOR  (two  new  input  parameters). 
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FIGURE  6.  OVERALL  ERROR  MESSAGE  LOGIC  FLOW 
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AMBIGUITY  REDUCTION  FACTOR  OF  OPTION  NR 

LEVEL  OF  AMBIGUITY  CUT  OFF  POINT 


FIGURE  7.  DETAILS  OF  ERROR  MESSAGE  PROCESSING 


17 


Another  new  input  parameter  -  PROBCR  -  is  used  to  determine 
whether  or  not  the  solution  selected  was  correct,  thereby  satisfying  the 
error  message.  If  the  error  message  is  not  satisfied  the  random  walk, 
is  entered  again. 

The  information  search  options  are  selected  with  a  probability 
(PROBOP)  equivalent  to  their  likelihood  of  being  used  by  an  operator  in  a 
real  TOS  system.  The  options  available  are  an  input  parameter.  After  an 
option  is  selected  (e.  g.  ,  glossary  lookups,  asking  another  operator),  the 
time  to  exercise  this  option  is  randomly  determined  from  a  normal  distribu¬ 
tion  with  mean  TIMCOR  and  standard  deviation  of  SDCOR  (new  input).  Each 
information  search  option  has  an  ambiguity  reduction  factor  associated  with 
it.  This  ambiguity  reduction  factor  is  the  amount  that  this  source  of  informa¬ 
tion  tends  to  move  the  decision  process  toward  reaching  a  solution.  It  is  ex¬ 
pressed  as  a  proportion  and  the  product  of  this  proportion  and  the  previous 
starting  point  within  the  random  walk  represents  the  new  starting  point  of 
the  random  walk.  For  example,  if  the  process  had  started  at  4,  an  ambigu¬ 
ity  reduction  of  factor  of  .  5  would  move  the  starting  point  to  2.  This  effect 
would  cause  the  probability  of  reaching  a  solution  in  the  random  walk  to  in¬ 
crease.  After  computing  the  new  starting  position,  the  random  walk  is 
started  again.  Again,  solution  or  no  solution  may  be  reached,  with  the  re¬ 
sults  described  previously. 


Details  of  Random  Walk  Processing 

Detailed  logic  for  the  subroutine  performing  the  random  walk  is  shown 
in  Figure  8.  The  starting  point  within  the  random  walk  is  determined  before 
the  subroutine  is  entered.  The  first  function  within  this  subroutine  is  to  initi¬ 
alize  conditions.  Next,  a  random  number  is  selected  to  be  compared  with  the 
probability  of  going  toward  a  solution  (PRBRT)  and  then  with  the  probability 
of  moving  toward  no  solution  (PRBWR).  These  probabilities  are  cumulative 
and  may  or  may  not  sum  to  1.  0  since  a  standstill  step  may  be  performed  and 
counted  within  the  random  walk.  After  each  step  is  taken,  the  resulting  posi¬ 
tion  is  tested  to  determine  whether  an  absorbing  state  has  been  reached.  If 
the  absorbing  state  has  not  been  reached,  another  random  step  is  triggered 
and  the  step  counter  (NSTEPS)  is  increased.  If  an  absorbing  state  has  been 
reached,  the  outcome  (NSOL)  is  noted  and  the  time  to  reach  the  solution 
(TMCOMP)  is  computed  as  a  function  of  the  total  number  of  steps  and  the 
time  required  to  take  each  step  (TSTEP).  Two  values  are  returned  to  sub¬ 
routine  error  message:  the  outcome  (solution  reached  or  no  solution  reached), 
and  the  time  required  to  reach  the  solution. 
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FIGURE  8.  DETAILS  OF  RANDOM  WALK  PROCESSING 
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Other  MANMOD  Modifications 

In  addition  to  the  MANMOD  modifications  and  coupling  described 
above,  a  number  of  other  changes  in  MANMOD  were  implemented: 


Interruption  due  to  incoming  messages.  The 
capability  to  simulate  the  interruption  which  re¬ 
sults  from  an  incoming  message  which  possesses 
a  higher  order  priority  than  a  message  being  pro¬ 
cessed  is  a  new  feature  which  has  been  added  to 
MANMOD.  To  accomplish  this  simulation  aspect, 
the  frequency  of  such  interruptions  along  with  the 
mean  time  duration  and  its  standard  deviation  are  pro¬ 
vided  as  input.  The  time  of  occurrence  of  each  in¬ 
terruption  is  randomly  selected  from  a  rectangular 
distribution  and  the  interruption  time  duration  is 
selected  from  a  normal  probability  distribution  on 
the  basis  of  the  input  mean  and  standard  deviation. 
Figure  9  presents  the  details  of  this  logic. 

Transmission  Delay.  Whenever  a  message  is  sent 
to  the  computer,  a  line  becomes  occupied.  Because 
operator  to  computer  lines  are  shared  by  a  number 
of  operators,  some  delay  may  occur  before  the  com 
puter  receives  and  responds  to  the  current  message. 
Simulation  of  this  delay  has  been  added  to  the  logic  of 
MANMOD  as  shown  in  Figure  10.  A  type  6  task  ele¬ 
ment  is  one  which  represents  sending  a  message  to 
the  computer.  In  this  case,  a  normal  deviate  is 
used  to  determine  the  transmission  time,  and  this 
time  is  added  to  the  processing  time.  This  trans¬ 
mission  delay  feature  is  also  shown  in  Figure  10 
for  the  case  in  which  a  corrected  message  is  inserted 
after  the  operator  has  received  an  error  message. 
This  new  feature  within  the  model  is  controlled  by 
the  new  input  variables  delay  [DEL(IH)]  and  delay 
standard  deviation  [DELSD(IH)].  These  variables 
may  be  entered  from  cards,  terminal,  or  read  from 
the  revised  CASE  generated  file. 
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FIGURE  10.  DETAILS  OF  TRANSMISSION  LOGIC 


CHAPTER  III 


SENSITIVITY  TESTS 


The  new  features  incorporated  into  the  MANMOD  were  tested  for 
sensitivity  by  varying  input  values  over  a  wide  range  and  measuring  the  ef¬ 
fects  of  this  variation  on  output.  The  test  values  were  not  selected  for  their 
realism.  Rather,  they  were  selected  to  assess  the  extent  to  which  the  new 
logic  reflected  appropriate  variation  to  a  range  of  conditions.  Tests  of  this 
kind  are  called  sensitivity  tests  and  provide  an  essential  part  of  the  evalua¬ 
tion  of  a  computer  model.  Adequate  sensitivity  is  a  necessary  ingredient 
in  any  computer  model. 


Error  Message  Logic  Sensitivity 

For  the  purposes  of  testing  the  sensitivity  of  the  error  message  logic 
(Figure  6),  the  error  message  handling  routines  of  MANMOD  were  separated 
from  the  rest  of  the  model.  Then  a  specified  number  of  messages  (an  N  of 
100  error  messages  was  used  on  all  runs)  could  be  executed  without  confound¬ 
ing  by  the  other  aspects  of  the  model. 

Figure  1 1  presents  the  effects  of  the  number  of  vocalic  center  groups 
on  error  message  processing  time.  As  the  number  of  vocalic  center  groups 
increased  from  4  to  16,  the  average  time  to  process  an  error  message  in¬ 
creased  from  109  to  201  seconds.  The  effect  was  in  the  anticipated  direction 
and  the  anticipated  linearity  was  evidenced  in  the  low  to  midrange.  Then  the 
effect  became  negatively  accelerated  at  (about  3  3  vocalic  center  groups). 

These  data  suggest  that  message  meaning  cognition  will  vary  from  about  1.  5 
minutes  to  over  3,  0  minutes.  This  result  seems- extremely  conservative  (i.  e. , 
in+he  direction  of  an  overestimate  rather  than  an  underestimate).  However,  the 
processing  time  certainly  reflects  the  input  variation  and  the  vocalic  center 
group  variation  seems  to  affect  strongly  simulation  results. 

.  The  random  walk  logic  depends  on  an  input  entry  relative  to  the  prob¬ 
ability  of  moving  toward  or  away  from  a  solution  at  any  step  of  the  walk.  The 
effects  of  varying  this  probability  or  random  walk  time  was  investigated  by 
varying  this  probability  over  a  range  of  values  from  .  10  to  .  90.  The  obtained 
result  is  presented  in  Figure  12. 
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ERROR  MESSAGE  PROCESSING  TIME  (SECONDS) 


As  the  probability  of  moving  towards  a  solution  decreased  from 
.  9  to  .  1,  the  mean  time  for  processing  an  error  message  increased  from 
96  to  551  seconds.  The  abscissa  of  Figure  12  is  given  in  probabilities. 

The  obtained  plot  (Figure  12)  shows  the  anticipated  form  because  exit  from 
the  random  walk  model  through  the  information  search  route  increases  the 
ambiguity  reduction  factor  for  the  next  entry  into  the  random  walk  process. 
Accordingly,  there  is  a  greater  chance  for  exit  through  the  solution  route 
on  the  second  random  walk  trial  than  on  the  first.  This  makes  common 
sense.  For  example,  an  operator  may  receive  several  possible  alternates 
from  a  given  information  source.  The  choice  ampng  remaining  alternates 
should  become  less  difficult  as  certain  alternates  are  eliminated  from  con¬ 
sideration. 

Within  the  MANMOD  logic,  when  a  simulated  operator  rece.ves 
and  perceives  the  meaning  of  an  error  message  and  does  not  see  a  solution, 
he  must  locate  correct  information.  Figure  13  presents  the  effects  of  in¬ 
creased  information  search  time  on  total  error  message  processing  time. 

This  increase  might  reflect  the  difference  between  consulting  a  readily 
available  handbook  as  opposed  to  a  prolonged  discourse  with  another  opera¬ 
tor.  For  sensitivity  test  purposes,  information  search  time  was  varied  be¬ 
tween  10  and  180  seconds.  The  resulting  error  message  processing  times 
ranged  from  77  to  219  seconds.  For  the  low  and  the  intermediate  conditions 
tested,  each  one  second  increase  in  search  time  produced  approximately  1.  5 
seconds  in  error  message  processing  time.  Accordingly,  within  the  model 
information  search  time  exerts  a  greater  effect  than  cognition  and  decision 
time.  This  seems  to  be  reasonable,  especially  if  a  manual  or  some  outside 
source  must  be  consulted.  The  effect  was  largely  linear,  as  would  be  antici¬ 
pated  since  this  search  time  is  largely  an  additive  function  in  the  model. 

When,  as  the  result  of  the  random  walk  logic,  a  solution  to  the  problem 
posed  by  the  error  message  is  reached,  a  revised  message  must  be  entered 
into  the  computer.  The  probability  that  any  given  solution  is  correct  should 
have  an  effect  on  the  time  required  to  process  error  messages.  Figure  14 
shows  the  effect.  Probabilities  over  the  range  of  .  10  to  .  90  were  tested. 

With  this  probability  variation,  the  resultant  mean  time  for  error  message 
processing  ranges  from  96  to  551  seconds.  The  time  increase  was  highly 
correlated  with  probability  decrease.  This  result  was,  of  course,  to  be  an¬ 
ticipated  due  to  the  large  number  of  random  walk  repetitions  to  be  anticipated 
from  low  probabilities.  For  example,  a  probability  of  .  10  can  be  anticipated 
to  produce,  on  the  average,  approximately  nine  times  as  many  repetitions  as 
a  probability  of  .  90  (number  of  repetitions  =  1/ probability  of  success). 


FIGURE  14.  THE  EFFECT  OF  PROBABILITY  OF  CHOOSING  A  CORRECT  SOLUTION  ON  ERROR  MESSAGE 

PROCESSING  TIME 


Combined  Probability 

As  indicated  in  Figure  7,  exit  from  the  error  message  subroutine  is 
dependent  on  two  probabilities.  The  first  of  these  probabilities  is  the  input 
entry  relative  to  the  probability  of  moving  toward  or  away  from  a  solution 
at  any  step.  The  second  probability  is  the  probability  that  the  achieved  solu¬ 
tion  is  correct.  At  this  point  in  the  logic,  a  random  number  (selected  from 
a  rectangular  distribution)  is  compared  with  an  input  probability.  The  re¬ 
sults  of  this  comparison  are  employed  to  determine  solution  correctness. 

The  effects  of  concurrent  variations  of  these  two  probabilities  were  tested. 

The  probability  of  reaching  a  solution  was  varied  over  the  range  from  .  10 
to  .  9Q  while  the  input  probability  relative  to  solution  correctness  was  varied 
over  the  same  range.  The  results  are  presented  in  Figure  15.  Again,  direc¬ 
tional  trends  were  indicated  in  the  anticipated  direction.  As  anticipated,  the 
effects  of  the  combination,  when  both  probabilities  were  low,  was  strong.  Ex¬ 
cept  for  extreme  values,  error  message  processing  time  seems,  within  the 
model,  to  be  about  equally  dependent  on  each  of  the  two  probability  numbers 
involved.  In  the  absence  of  empirical  data  to  the  contrary,  this  effect  seems 
justifiable. 

Other  Tests  of  Sensitivity 


Two  other  features  tested  in  these  sensitivity  tests  were  the  trans¬ 
mission  delay  simulation  and  the  incoming  message  interruption  simulation 
implemented  in  MANMOD.  The  transmission  delay  time  is  an  additive  to  the 
time  to  perform  the  task  and  due  to  its  relatively  low  value  is  usually  minimum 
in  comparison  with  the  total  task  performance  time.  The  effects  were  linear 
as  anticipated  from  the  logic  involved. 

Incoming  messages  of  priority  higher  than  routine  interrupt  the  mes¬ 
sage  in  process  (if  any)  and  produce  a  delay.  Test  runs  were  made  with  an 
interruption  duration  of  60  seconds  with  a  standard  deviation  of  2.  5  seconds. 

Two  conditions  were  compared:  (1)  interruption  frequence  of  5  times  per  hour, 
and  (2)  a  frequency  of  10  times  per  hour.  These  frequencies  produced  mean 
message  processing  times  of  244.  9  and  327.4  seconds.  As  seems  reasonable, 
an  increased  frequency  of  interrupted  messages  caused  an  increased  processing 
time  for  the  original  message.  This  increase  reflects  the  increase  in  time  re¬ 
quired  to  repeat  a  part  of  the  processing  of  an  interrupted  message,  as  well 
as  the  delay  while  waiting  for  the  incoming  message  to  get  through. 
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PROBABILITY  OF  REACHING  ANY  SOLUTION 


FIGURE  15.  THE  EFFECTS  OF  COMBINATION  OF  THE  PROBABILITY  OF  REACHING 
ANY  SOLUTION  AND  THE  SOLUTION  BEING  CORRECT 
FOR  ERROR  MESSAGE  PROCESSING  TIMES 


CHAPTER  IV 


DISCUSSION,  SUMMARY,  AND  CONCLUSIONS 


The  goals  of  the  present  program  were  to  couple  the  MANMOD, 

CASE,  and  SAMTOS  models  so  that  the  strongest  features  of  each  can  be 
exercised  in  an  integrated  TOS  simulation  and  to  strengthen  the  MANMOD 
so  as  to  allow  greater  simulation  fidelity.  Both  of  these  goals  were  achiev¬ 
ed.  The  coupled  CASE  and  MANMOD  computer  simulation  may  now  be  per¬ 
formed  on  the  U  1108  system  and  the  results  entered  directly  to  SAMTOS. 

This  approach  achieved  the  desired  coupling  without  modifying  SAMTOS 
in  any  way.  Modification  of  the  SAMTOS  program  was  considered  to  be  un¬ 
desirable  because  SAMTOS  is  written  in  a  special  language  and  because  cer¬ 
tain  subroutines  in  the  model  are  not  the  sole  property  of  the  government. 
Accordingly,  the  cost  of  such  a  modification  would  exceed  the  benefit  to  be 
obtained  from  direct  integration. 

The  MANMOD  has  been  previously  validated  (Siegel,  Wolf,  &  Leahy, 
1973)  and  found  to  produce  results  which  agree  quite  well  with  criterion  data. 
There  is  little,  if  any,  reason  to  believe  that  the  coupling  of  MANMOD  with 
CASE  and  the  modifications  introduced  into  MANMOD  during  the  course  of 
the  present  work  will  exert  a  negative  influence  on  this  previously  suggested 
validity.  However,  continuous  verification  of  such  models  is  certainly  de¬ 
sirable.  At  the  minimum,  it  seems  desirable  to  validate  the  newly  imple¬ 
mented  error  message  processing  aspects  of  the  MANMOD. 

The  results  of  the  sensitivity  tests  indicated  that  the  message  proc¬ 
essing  time  output  is  sensitive  to  variation  of  the  input  parameters  which 
directly  affect  this  logic.  All  tests  completed  supported  the  contention  that 
these  modifications  yield  an  output  in  the  anticipated  direction.  An  assess¬ 
ment  of  whether  or  not  the  magnitudes  indicated  are  realistic  would  depend 
on  the  availability  of  criterion  data,  as  discussed  above. 

It  seems,  however,  that  the  Army  now  has  available  a  flexible  simu¬ 
lation  tool  which  can  be  used  to  assess  various  aspects  of  the  TOS  and  sim¬ 
ilar  communications  systems.  When  the  MANMOD  itself  and  the  coupled 
models  are  considered,  there  seems  to  be  available  the  ability  to  simulate 
and  investigate  the  effects  of  varying  items  such  as  qualitative  and  quanti¬ 
tative  aspects  of  the  manning,  message  load,  equipment  characteristics  and 
delay  times,  message  type,  and  watch  length  on  system  effectiveness.  More¬ 
over,  the  output  will  state  not  only  that  a  given  effectiveness  level  was  or  was 
not  achieved  but  also  what  contributed  to  any  failures  noted.  The  output  de¬ 
tail  can  provide  insights  relative  to  equipment  design  modification,  training 
requirements  and  objectives,  personnel  requirements,  and  tradeoffs. 
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Summary  and  Conclusions 

In  order  to  provide  a  more  powerful  tool  for  simulating  the  TOS  and 
similar  communications  systems,  three  previously  developed  and  independ¬ 
ent  models  were  coupled.  The  three  models  considered  were;  MANMOD, 
CASE,  and  SAMTOS.  In  the  coupled  form,  the  message  delay  data  gener¬ 
ated  by  a  revision  of  CASE  are  employed  as  input  to  the  MANMOD.  The 
MANMOD  then  employs  these  data  within  its  simulation  of  the  message 
processing  by  the  system  operators.  The  output  of  the  combined  simula¬ 
tion  is  in  a  form  that  it  can  be  entered  directly  into  SAMTOS,  which  simu¬ 
lates  further  equipment  delay  aspects. 

During  the  course  of  the  integration  effort,  a  number  of  improve¬ 
ments  were  introduced  into  the  logic  of  the  MANMOD.  These  improvements 
were  largely,  but  not  exclusively,  concerned  with  the  simulation  of  error 
message  processing.  The  modifications  were  tested  for  sensitivity  and  rea¬ 
sonableness  of  effect  on  model  output.  The  modifications  were  believed  to 
be  acceptable  from  the  point  of  view  of  both  of  these  criteria. 

The  following  conclusions  seem  to  be  indicated: 

1.  An  integration  has  been  attained  of  the  MANMOD  with 
a  revised  CASE  and  the  SAMTOS  models. 

2.  The  combined  model  should  allow  the  simulation  of  the 
effects  of  a  host  of  human,  message,  and  equipment 
parameters  on  the  effectiveness  of  TOS  and  similar 
communication  systems. 

3.  The  various  modifications  of  the  MANMOD,  imple¬ 
mented  during  the  course  of  the  present  work,  seem 
to  produce  effects  which  will  serve  to  enhance  model 
utility. 

4.  Validation  of  the  newly  developed  effects  seems  re¬ 
quired  and  calibration  may  be  necessary. 
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6ERTS  QR  Simulation  of  Message  Traffic  in  a  Computer  System 
A  simulation  of  message  traffic  in  a  computer  system  was  developed 
to  interface  with  the  MANMODEL.  The  simulation  yields  system  performance 
measures  such  as  message  response  times  (waiting  time  plus  service  time) 
and  utilization  statistics  for  equipment  components  of  the  computer  system. 
Summary  measures  and  distributions  resulting  from  the  simulation  model  may 
be  provided  as  input  to  the  MANMODEL.  This  enables  man-machine  relation¬ 
ships  modeled  in  the  MANMODEL  to  include  machine  dependent  times  representa¬ 
tive  of  a  particular  computer  system  configuration. 

The  simulation  emphasizes  queueing  aspects  of  message  flow  through 
computer  system  components  and  is  accomplished  with  the  GERTS  QR  simulator 
(references  1 ,2  and  3).  This  simulator  is  tailored  to  the  simulation  of 
Graphical  Evaluation  and  Review  Technique  (GERT  -  references  4  and  6) 
probabilistic  networks  and  is  FORTRAN  based.  The  GERTS  QR  simulator  combines 
capabilities  of  previous  GERTS  simulators  (references  5  and  6).  These 
capabilities  include  features  for  handling  queues  in  the  network  and  resource 
limitations  on  activities  in  the  network. 

This  appendix  provides  a  short  description  of  network  simulation  with 
GERTS  QR  and  then  describes  the  example  network  model  which  was  developed 
to  demonstrate  the  MANMODEL  interface.  A  listing  of  required  input  for 
GERTS  QR  is  also  provided  as  well  as  samples  of  the  output  report  statistics 
produced  by  the  simulator  for  this  example. 
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Network  Representation  for  Simulation  with  GERTS  QR 


Basic  features  and  notation  associated  with  GERTS  network  simulation 
are  described  in  references  2,5,  and  6.  The  basic  network  features  and 
specific  capabilities  of  the  GERTS  QR  simulator  are  briefly  summarized  here. 

Networks  are  made  up  of  nodes  and  branches  which  represent  events  and 
activities,  respectively,  from  the  process  to  be  modeled.  Source  nodes 
initiate  activities  at  the  network  origin  while  sink  nodes  terminate  specific 
paths  through  the  network.  Various  node  types  are  available  for  regulating 
the  flow  of  entities  through  the  network  and  collecting  statistics.  Node 
output  sides  may  be  deterministic  or  probabilistic  in  the  selection  of 
branches  to  follow  after  node  release.  Thus,  each  branch  in  the  network 
is  characterized  by  a  probability  of  selection  as  well  as  a  time  (constant 
or  random  variable)  for  activity  performance  given  selection.  In  this  manner, 
entities  are  initiated  and  pass  through  the  network  to  termination  for  a  pre¬ 
set  number  of  network  realizations.  Statistics  are  collected  during  each 
pass  through  the  network  to  include  probabilities  that  events  and  activities 
of  interest  will  be  realized  and  the  associated  times  for  realization. 

The  specific  capabilities  of  the  GERTS  QR  simulator  provide  an  additional 
node  type,  the  queue  node,  and  allow  the  association  of  resource  requirements 
with  each  service  activity  following  a  queue  node.  Entities  passing  through 
the  network  may  wait  at  designated  queue  nodes  in  the  network  for  service 
at  the  queue  facility.  These  service  activities  may  require  single  or  multiple 
homogeneous  resources. 

The  programs  of  the  GERTS  QR  simulator  then  allocate  resources  to  service 


activities  according  to  user  supplied  scheduling  options  and  resource  availability 
Total  resources  available,  by  type,  are  specified  as  inout  by  the  user.  Service 


activities  which  have  been  released  (predecessor  activities  in  the  network 
have  been  completed)  are  placed  in  a  file  pending  a  check  of  resource 
availability.  Activities  from  this  file  for  which  resources  are  available 
are  placed  in  a  second  file  as  candidates  for  scheduling.  As  activities  are 
selected  for  accomplishment,  resources  are  allocated  and  available  resources 
reduced  accordingly.  Activities  which  cannot  be  scheduled  following  resource 
allocation  to  other  activities  are  removed  to  the  first  file  to  wait  for 
resources.  This  means  that  entities  whose  flow  through  the  network  is 
being  simulated  may  be  delayed  (1)  in  queues  waiting  to  enter  a  service 
activity  and  also  (2)  after  entry  to  the  service  activity  due  to  lack  of 
sufficient  resources. 
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Description  of  the  Three  Program  Level  Example  Network 

The  network  in  Figure  -1  depicts  the  flow  of  entities  (messages 
or  jobs  in  this  case)  through  the  queues  and  resource  constrained  activities 
which  represent  the  computer  system  for  this  example.  Three  program  levels 
are  modeled  which  represent  the  priority  arrangement  through  which  jobs 
are  selected  for  computer  execution.  Program  levels  are  a  hardware 
feature  of  certain  actual  computers  (Litton  AN/GYK-12).  A  division  of 
incoming  jobsis  also  commonly  based  on  memory  requirements;  such  a  division 
results  in  ordering  jobs  for  memory  partitions.  In  this  example,  program 
levels  are  modeled  and  each  program  level  is  allocated  a  separate  memory 
region. 

The  example  model  assumes  that  a  specific  remote  job  entry  location 
is  of  interest.  The  job  stream  entered  from  this  location  is  termed 
foreground  load  while  the  remainder  of  the  load  simulated  is  termed  back¬ 
ground. 

Activity  2-3  in  the  network  initializes  the  background  load  while 
activity  2-4  initializes  the  foreground  load.  The  foreground  job  stream 
emanates  from  node  4  and  proceeds  to  queue  node  9.  Service  activity 
9-10  represents  communications  transmission  to’  the  computer  location. 

The  loop  on  node  4  determines  the  inter-arrival  times  for  the  foreground 
load  stream.  Node  8  is  a  statistics  node  to  verfiy  the  input  load 
inter-arrival  times  generated.  From  node  10,  a  probabilistic  node, 
incoming  jobs  are  routed  to  one  of  the  three  program  levels  according  to 
a  specified  probability.  Queue  node  12  represents  entry  to  program  level 
1  (first  priority)  for  the  foreground  job  stream.  Queue  nodes  14  and  16 
represent  entry  to  program  levels  2  and  3,  respectively. 


Figure  -1:  Network  Diagram,  Three  Program  Level  Example 


The  network  paths  from  node  12  to  41,  14-45,  and  16-49  include 
activities  w‘  -h  represent  computer  processing  for  program  levels  1-3 
of  the  foreground  job  stream.  As  modeled,  this  computer  processing 
first  requires  reading  jobs  into  core  from  a  random  access  device  (RAD). 
Central  processing  unit  (CPU)  activity  is  then  required  followed  by  data 
accesses  which  may  be  required  to  the  RAD  with  a  specified  probability. 
This  CPU  activity,  random  data  access  cycle  continues  in  turn  on  an 
intermittent  basis  according  to  device  availability  until  the  job  is 
completed.  Upon  completion,  the  job  is  read  out  to  the  RAD. 

On  the  network  diagram,  service  activity  12-18  represents  the 
reading  in  of  a  program  level  1  job  from  the  foreground  stream. 

Service  activity  23-24  represents  CPU  activity  while  25-26  represents  RAD 
accesses.  Job  routing  to  queue  node  25  is  handled  probabilistically 
from  node  27  in  the  case  of  foreground  jobs.  Node  27  is  placed  into 
the  network  (replacing  node  24)  through  the  network  node  modification 
feature  which  allows  node  output  changes  during  the  course  of  the 
simulation.  This  allows  foreground  and  background  jobs  to  share  the 
same  queue  nodes  representing  computer  processing  activities  with  a 
resulting  savings  in  the  size  of  the  network  to  be  simulated.  When 
activity  27-40  is  selected  (according  to  the  probability  specified) 
the  job  has  completed  and  activity  40-41  represents  reading  the  job  out 
to  the  RAD. 

Following  computer  processing  activities,  the  resulting  output 
is  transmitted  back  to  the  remote  job  entry  site  for  jobs  from  the 
foreground  stream.  Service  activities  50-51,  52-53  and  54-55  represent 
program  level  1-3  output  transmissions.  At  the  conclusion  of  output 
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transmission,  statistics  are  collected  on  the  computer  system  response 
time.  For  the  foreground  stream  this  interval  is  collected  for  in¬ 
dividual  jobs  on  each  of  the  three  program  levels.  An  I  appears  below 
nodes  51,  53  and  55  to  designate  an  Interval  statistics  node.  Interval 
statistics  are  collected  at  these  points  measured  from  the  time  the 
job  was  tagged  at  node  4,  a  Mark  node,  to  indicate  system  entry  time. 

The  background  portion  of  the  network  allows  simulation  of  the 
computer  system  load  in  addition  to  the  remote  job  entry  site  of  particular 
interest.  Contention  for  resources  between  foreground  jobs  and  the 
background  job  stream  is  represented  in  this  manner.  Background  job 
loads  may  be  adjusted  on  each  of  the  three  program  levels,  as  represented 
by  self-loops  establishing  inter-arrival  times  on  nodes  5,  6  and  7  for 
program  levels  1,  2  and  3,  respectively.  No  communications  transmissions 
are  represented  for  the  background  job  streams.  Computer  processing 
activities  are  handled'  in  the  same  manner  as  discussed  for  the  foreground 
jobs,  with  separate  activities  for  reading  background  jobs  in  from  and  out 
to  the  RAD.  For  example,  service  activity  11-17  represents  reading  in 
program  level  1  background  jobs  while  38-39  represents  read  out.  This 
permits  separate  interval  statistics  to  be  collected  on  the  simulated 
computer  processing  times  for  background  jobs.  Interval  statistics  are 
collected  for  each  program  level  at  nodes  39,  43  and  47.  Between  statistics 
(node  58)  are  then  collected  on  all  background  jobs  to  assist  in  determining 
the  output  rate  of  the  modeled  system. 

The  network  diagram  also  includes  a  "balk"  node  (59),  to  which 
jobs  are  routed  if  designated  queue  capacities  are  exceeded.  Queue  nodes 
in  the  computer  processing  portion  of  the  network  are  designated  as 
zero  entry  queues  since  only  one  job  is  allowed  on  each  program  level 
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(utilizing  the  corresponding  memory  region)  at  once.  Jobs  resident  on 
a  level  must  either  be  in-process  or  waiting  for  resources  (processor 
or  devices).  In  this  situation,  balking  jobs  constitute  an  error  condi¬ 
tion  and  realization  of  node  59  and  60  indicate  the  occurrence  of  such 
an  error  during  the  course  of  a  simulation  run.  Queue  nodes  38,  40, 

42,  44,  46  and  48  are  also  zero  entry  queues  although  links  to  node 
59  have  been  excluded  from  the  diagram. 

Nodes  56  and  57  are  utilized  to  produce  an  intermediate  report 
after  a  specified  number  of  foreground  jobs  have  been  simulated  and 
final  reports  after  a  specified  number  of  sets  of  foreground  jobs  have 
been  simulated.  For  example,  node  56  may  be  realized  after  50  jobs  are 
processed.  This  causes  activity  56-57  to  be  accomplished  producing 
an  intermediate  report.  Node  57  may  be  realized  after  1,  5,  10  or  some 
other  arbitrary  number  of  sets  of  50  jobs  each.  Node  57  (a  sink 
node)  terminates  the  simulation  on  realization  and  produces  final  reports 
for  the  total  number  of  jobs  simulated  (50^  250,  500  etc.). 

For  this  example,  all  queues  are  ordered  on  a  first  in  first  out  (FIFO) 
basis.  Resource-allocation  and  scheduling  files  are  also  ordered  on  a  FIFO 
basis  according  to  the  time  each  job  was  tagged  at  a  mark  node  designating 
system  entry  time.  Activities  corresponding  to  program  execution  within 
a  memory  region  are  further  scheduled  on  a  priority  basis  with  program 
level  1  receiving  first  priority.  Activities  are  also  screened  to  insure 
single  job  occupancy  in  a  memory  region  during  read  in,  execution,  and 
read  out  operations  requiring  the  CPU.  Allocating  resources  to  service 
activities  in  order  of  priority  and  screening  to  hold  a  specific  resource 
over  a  series  of  service  activities  requires  a  user  modification  to  the 
standard  6ERTS  QR  scheduling  subprogram.  Additional  user  modifications 
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provide  intermediate  and  final  summary  statistics  tailored  to  the  present 
example.  Since  the  GERTS  QR  simulator  is  FORTRAN  based,  these  modifications 
are  readily  accomplished. 

Resources,  by  type,  for  the  example  are  listed  below: 

Resource  Type  Number  Available 

CPU  1  1 

Memory  Region  1  2  1 

Memory  Region  231 
Memory  Region  3  4  1 

Randon  Access  Devices  5  2 

Communications  Channel  6  1 

The  communications  channel  is  required  by  service  activities  representing 
communications  transmission  to  and  from  the  computer  location.  For  example, 
service  activities  9-10  and  50-51  for  program  level  1  of  the  foreground  job 
stream  require  the  communications  channel,  resource  type  6.  Read  in 
service  activities  (e.g.  12-18),  from  the  RAD  to  core,  require  the  CPU,  corres¬ 
ponding  memory  region  (1  for  service  activity  12-18),  and  one  RAD  (two  are 
available).  Serviceactivities  representing  processing  by  the  CPU  (e.g.,  23-24) 
require  the  CPU  and  the  corresponding  memory  region  (1).  RAD  accesses 
(e.g.,  service  activity  25-26)  require  one  RAD  and  the  corresponding 
memory  region  (1).  Read  out  service  activities  (e.g.,  40-41)  require  the 
same  resources  as  'or  reading  into  core. 

This  completes  the  description  of  the  example  network.  Required  input 
data  for  the  simulator  is  next  listed  with  the  required  card  formats. 

Sample  output  report  statistics  from  the  example  are  then  listed. 
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Required  Input  to  the  GERTS  QR  Simulator 

Table  -1  lists  required  input  card  types  and  data  fields  for 
the  GERTS  QR  simulator.  The  GERTS  QR  programs  are  installed  at  Edge- 
Wood  Arsenal  on  the  UNIVAC  1108  to  interface  with  the  MANMODEL. 
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Table  -1:  Input  Data  Format 
(Version  1/29/75) 


DATA  CARD  0* 

Field  1 

Total  number  of  jobs  (entities)  passing  through 
all  queues  (15)- 

Field  2 

Number  of  jobs  in  each  set  to  be  simulated  between 
calls  to  produce  intermediate  report  statistics  ( I 5 ) * 

Field  3 

Set  equal  to  1  to  produce  intermediate  report 
statistics  (15)* 

Field  4 

Not  required  (15)* 

Field  5 

Not  required  (15). 

Field  6 

Not  required  (15). 

Field  7 

Number  of  program  levels  (or  priority  levels) 
for  which  jobs  must  be  scheduled  (15)* 

DATA  CARD  1 

Field  1 

The  analyst's  name  (6A2,l). 

Field  2 

The  project  number  (l4,l)  (if  negative,  data 
card  7  is  required  to  indicate  the  runs  to  be 
traced) . 

Field  3 

The  month  number  (I2,l). 

Field  4 

The  day  number  (l2,l). 

Field  5 

The  year  (l4,l). 

Field  6 

The  number  of  times  the  network  is  to  be  simulated 
(14,1). 

Field  7 

The  number  of  activities  with  different  time 
characteristics  (l4,l). 

Field  8 

The  number  of  branches  in  the  network  plus  an 
estimate  of  the  maximum  number  of  activities  which 
can  occur  simultaneously  (l4,l). 

♦Note:  Only  fields  3  and  7  are  required  since  PURGE  options  are  not 
exercised  in  this  version.  For  three  program  level  example, 
a  1  is  required  in  col  15  and  a  3  in  col  35* 
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Field  9 


An  integer  random  number  seed  (ll8,l).  Right 
Justified  to  col.  5^« 


Field  10 

DATA  CARD  2 
Field  1 

Field  2 
Field  3 
Field  4 

Field  5 

Field  6 
Field  7 

Field  8 
Field  9 

Field  10 

Field  11 
Field  12 
Field  13 


A  floating  point  random  number  seed  (F10.4,l). 
Not  required  for  this  version. 


The  largest  node  number  of  the  network  including 
all  possible  modifications  to  the  network  (I3,l) 
Note:  the  smallest  node  number  permitted  is  2. 

Number  of  source  nodes  (I3,l). 

Number  of  sink  nodes  (l3,l). 

Number  of  sink  nodes  that  must  be  realized  before 
the  network  is  realized  (l3,l). 

Number  of  nodes  which  statistics  are  to  be  collected 
on,  including  all  sink  nodes  (l3,l). 

Number  of  types  of  counts  (I3,l). 

A  1  if  network  modifications  exist;  a  0  otherwise 

(13,1). 

Number  of  different  resource  types  (I3,l). 


The  attribute  on  which  ranking  is  to  be  done 
for  files  NOQ  and  (NOQ-l).  Add  100  to  attribute 
number  if  a  JTRJB  value  is  to  be  ranked  on  (l3,l). 


The  priority  system  to  be  used  for  files  NOQ  and 
(NOQ-l).  A  1  indicates  low -value  first.  A  2 
indicates  high-value  first  (l3,l). 

Number  of  available  resources  of  Type  1  (I3,l). 


Number  of  available  resources  of  Type  2  (I3,l). 
Number  of  available  resources  of  Type  3.  (I3>l)« 


Field  20 


Number  of  available  resources  of  Type  10  (l3,l). 
Maximum  of  10  resource  types  for  this  version. 
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DATA  CARD  3 

One  data  card  for  each  node  in  the  network 


Field  1 

Field  2 


Field  3 
Field  4 
Field  5 

Field  6 

Fields  7, 

Field  7 

Field  8 


The  node  nuinber  (descriptor)  associated  with  the 
node  characteristics  given  on  this  card  (13,1). 

Special  characteristic  of  the  node.  Codes  for 
special  .characteristics  are: 

1.  Source  node 

2.  Sink  node 

3.  Node  on  which  statistics  are  collected 

4.  A  mark  node 

5*  Q  Node-See  description  for  Q-Nodes  which  follows 

IF  Field  2  is  left  blank,  so  special  characteristic 
is  associated  with  the  node  (I3,l). 

The  number  of  releases  required  to  realize  the 
node  for  the  first  time.  (I3,l). 

The  number  of  releases  required  to  realize  the  node 
after  the  first  realization  (I3,l). 

Output  characteristic  of  the  node.  Codes  for 

input  are:  P  for  Probabilistic;  and  D  for  Deterministic 

(Al,l). 

If  events  that  have  been  scheduled  to  end  on  this 
node  are  to  be  removed  (cancelled)  when  this  node 
is  realized,  an  "R”  should  be  put  in  this  field. 

If  removal  isnot  desired,  leave  blank  (Al,l). 

8  and  9  are  used  only  if 

The  node  is  a  sink  node  or  a  statistics  node 
(code  2  or  3  in  field  .2). 

The  lower  limit  of  the  second  cell  for  the  his¬ 
togram  to  be  obtained  for  this  node.  The  first 
cell  of  the  histogram  will  contain  the  number 
of  times  thenode  was  realized  in  a  time  less  than 
the  value  given  in  this  field  (F6.2,l). 

The  width  of  each  cell  of  the  histogram.  Each 
histogram  contains  20  cells.  The  last  cell  will 
contain  the  number  of  times  the  node  was  realized 
in  a  time  greater  than  or  equal  to  the  lower  limit 
(specified  in  Field  7)  +  18  *  (cell  width  (specified 
by  Field  8))  (F6.2,l). 


Field  9 


Statistical  quantities  to  be  collected  (Al,l) 


Field  10 

Field  11 

Field  12 

Data  Card 
For  Q-Nodes 
Field  1 
Field  2 
Field  3 

Field  4 

Field  5>6 
Field  7,  6 

Field  9 
Field  10 


F.  The  time  for  first  realizations  of  the  node 

A.  The  time  of  all  realizations  of  the  node 

B.  The  time  between  realizations  of  the  node 
I.  The  time  interval  required  to  go  between 

two  nodes 

D.  The  time  delay  from  first  activity  completion 
on  the  node  until  the  node  is  realized 

Only  required  for  Q  nodes.  See  For  Q-Nodes 
description  which  follows  (I3,l). 

Only  required  for  Q  nodes.  See  For  ■'.Q-Nodes 
Description  which  follows  (l3>l). 

Histogram  plot  and  copy  option.  Set  to  1  to 
plot  histogram  for  node  described.  Also  copies 
histogram  identification  and  frequency  counts 
to  attached  external  file  (I3,l). 


Same  as  for  Data  Card  3  described  above. 

Code  for  a  Q-node  is  5 • 

For  a  Q-node,  the  initial  number  in  the  queue. 

If  greaterithan  zero,  the  service  activity  is 
assumed  busy  and  an  end  of  service  activity 
event  is  defined  automatically. 

For  a  Q-node,  -1  to  indicate  maximum  number  in 
queue  is  0,  0  to  indicate  no  limit  on  number  in 
the  queue,  otherwise  the  maximum  number  allowed 
in  the  queue . 

Not  required  for  Q-nodes. 

Lower  limit  of  cell  2  and  width  of  each  cell 
for  statistics  on  the  average  number  in  the  queue. 

Not  required  for  Q-nodes. 

Priority  Ranking  Procedure  for  the  Q-nodes  (I3,l) 
0  -  First-in  -  first-out  (FIFO) 

1  -  Last-in  -  first-out  (LIFO) 
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Field  11 


Node  that  is  transferred  to  when  an  activity  is 
completed  that  is  incident  to  the  Q-node  and 
the  maximum  number  allowed  is  in  the  queue 
(the  node  to  which  an  item  balks)  (13, l). 

Field  12  Same  as  for  Data  Card  3  described  above. 

NOTE;  The  last  card  of  this  type  must  have  a  zero  in  Field  1  . 

DATA  CARD  4 


The  parameters  associated  with  the  distribution 
of  the  time  to  perform  each  activity.  One  card 
is  required  for  each  activity  with  a  different 
time  characterization.  The  number  of  cards  is 
specified  by  Data  Card  1,  Field  7.  A  maximum 
of  30  is  permitted.  The  cards  must  be  arranged 
by  ascending  parameter  number  and  the  parameters 
must  be  numbered  consecutively  or  blank  cards 
appropriately  placed.  Eleven  distribution  types 
are  available  which  are: 

1.  Constant 

2.  Normal 

3*  Uniform 

.4.  Erlang  (Exponential  optional) 

5-  Lognormal 

6.  Poisson 

7.  Beta 

8.  Gamma 

9.  Beta  (Fitted  to  three  parameters  as  in  PERT). 

10.  Triangular 

11.  Hyper -exponential  (For  given  values  of  overdispersion). 
The  fields  required  are  dependent  on  the  distribution 

type  of  activity.  See  Definitions  of  Parameters 
for  Random  Deviate  Sampling  following  this  description 
of  input  data  formats . ' 


DATA  CARD  5 

One  data  card  for  each  activity  associated  with  the  network. 


Field  1 

Probability  of  realization  (F8,3,l)* 

Field  2 

Start  node  (I3,l). 

Field  3 

End  node  (l3,l). 

Field  4 

Parameter  number  (l3,l). 

Field  5 

The  distribution  type  (l3>l)« 

Field  6 

Count  type  (l3>l)* 

Field  7 

Activity  number  (l3,l). 

Field  8 

Number  of  resources  of  type  1  required 
activity  (I3,l)* 

for 

the 

Field  9 

Number  of  resources  of  type  2  required 
activity  (l3>l). 

for 

the 

Field  10 

Number  of  resources  of  type  3  required 
activity  (13^1). 

for 

the 

Field  17  Number  of  resources  of  type  10  required  for  the 

activity  (I3,l). 

NOTE:  The  last  data  card  of  this  type  must  have  a  zero  (or  blank) 
in  Field  2. 


DATA  CARD  6  (Optional) 

Only  required  if  network  modifications  exist,  i.e.,  if  the  number  of 

nodes  modified  is  greater  than  zero.  (Field  7,  Data  Card  2). 

Field  1  An  activity  number  (l3,l)* 

Field  2  The  number  of  the  node  to  be  replaced  if  the 

activity  given  in  Field  1  is  realized  (13,1). 

Field  3  The  number  of  the  node  to  be  inserted  into  the 

network  in  place  of  the  node  specified  in  Field  2 
when  the  activity  in  Field  1  is  realized  (I3,l). 


Field  2  and  3  are  repeated  if  the  activity  given 
in  Field  1  affects  multiple  nodes.  A  zero  in  an 
even-numbered  field  indicates  the  end  of  the  data 
on  the  card. 


Fields 
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DATA  CARD  7  (Optional) 

Only  used  if  the  project  nun  bar  is  negative*.  (Field  2,  Data  Card  l). 

Field  1  The  run  number  for  which  tracing  of  the  end  of 

activity  events  should  begin  (13,1). 

Field  2  The  run  number  for  which  tracing  of  the  end  of 

activity  events  should  terminate  (l3,l). 

*  Negative  project  number  produces  TRACE  option,  a  debugging  aid.  Each 
activity  realized  during  the  course  of  the  TRACE  produces  two  lines 
of  printed  output.  To  avoid  reams  of  output,  care  must  be  exercised 
when  the  TRACE  option  is  elected  to  limit  the  total  number  of  activities 
simulated. 

Multiple  networks  can  be  analyzed  by  stacking  the  data  cards  as  described 
above,  one  after  another.  No  blank  cards  should  separate  the  data 
cards  for  each  network. 

NOTE:  Two  blank  cards  are  required  to  indicate  the  end  of  all  networks 
to  be  simulated. 
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Definitions  of  Parameters  for  Random  Deviate  Samplim 


The  parameters  required  on  Data  Card  Type  4  to  sample  from  the 

nine  distributions  available  in  GERTS  III  are  described  below. 

For  distribution  type  1  (Constant): 

Field  1  The  constant  time  (FIO.4,1). 

For  distribution  type  2  (Normal) ;  5 (Lognormal) ;  7  (Beta);  and  8 (Gamma): 

Field  1 

The  mean  value  (FIO.4,1). 

Field  2 

The  minimum  value  (FIO.4,1). 

Field  3 

The  maximum  value  (F10.4,l). 

Field  4 

The  standard  deviation  (FIO.4^1). 

For  distribution  type  3  (Uniform): 

Field  1 

Not  used  (F10.4,l). 

Field  2 

The  minimum  value  (F10.4,l). 

Field  3 

The  maximum  value  (F10.4,l). 

Field  4 

Not  used  (F10.4,l). 

For  distribution  type  4  (Erlang): 

Field  1 

The  mean  time  for  the  Erlang  variable  divided 

by  the  value  given  to  Field  4  (F10.4,l). 

Field  2 

The  minimum  value  (F10.4,l). 

Field  3 

The  maximum  value  (F10.4,l). 

Field  4  The  number  of  exponential  deviates  to  be  included 

in  the  sample  obtained  from  the  Erlang  distribution 

(F10.4,l). 

If  Field  4  is  set  equal  to  l,.an  exponential  deviate  will  be  obtained 
from  distribution  type  4. 


For  distribution  type  6  (Poisson); 


Field  1  The  mean  minus  the  minimum  value  (F10.4,l). 


Field  2  The  minimum  value  (F10.4,l). 

Field  3  The  maximum  value  (F10.4,l). 

Field  4  Not  used  (F10.4,l). 

Care  is  required  when  using  the  Poisson  since  it  is  not  usually  used 
to  represent  an  interval  of  time .  The  interpretation  of  the  mean  should 
be  the  mean  number  of  time  units  per  time  period. 

For  distribution  type  9  (Beta  fitted  to  3  values  as  in  Pert)  and  10 

(Triangular) : 

Field  1 

The  most  likely  value,  m  (F10.4,l). 

Field  2 

The  optimistic  value,  a  (F10.4,l). 

Field  3 

The  pessimistic  value,  b  (F10.4,l). 

Field  4 

Not  used 

For  distribution  type 

11  (Hyperexponential): 

Field  1 

The  mean  value  ( F10 . 4 , 1 ) . 

Field  2 

The  minimum  value  (F10.4,l). 

Field  3 

The  maximum  value  (Fl0.4,l). 

Field  4 

The  standard  deviation  which  should  be  greater 
than  Field  1.  The  amount  by  which  the  standard 
deviation  exceeds  the  mean  reflects  the  amount 
of  overdispersion  to  be  produced  by  sampling 
from  two  parallel  exponential  random  processes. 

NOTE:  Samples  are  obtained  from  the  distributions  such  that  if  a  sample 
is  less  than  the  minimum  value,  the  sample  value  is  given  the  minimum 
value.  Similarly,  if  the  sample  is  greater  than  the  maximum  value, 
the  sample  value  is  assigned  the  maximum  value.  This  is  not  sampling 
from  a  truncated  distribution  but  sampling  from  a  distribution  with  a 
given  probability  of  obtaining  the  minimum  and  maximum  values. 


Table  •  -2  lists  sample  output  from  a  simulation  run  of  the  three 


program  level  example  network.  Sections  of  the  intermediate  reports 
and  final  results  for  the  simulation  run  are  displayed  in  Table  -2 
under  these  labels.  A  final  output  report  tailored  to  the  example  is  also 
labeled  and  illustrated. 


Final  Results  for  Resource  Utilization 
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